1. Field of the Invention
The present invention relates to the field electronic design automation (EDA). More specifically, embodiments of the present invention relate to an EDA system having an improved physical design system for hierarchical integrated circuit designs.
2. Related Art
An electronic design automation (EDA) system is a computer system used for designing integrated circuit (IC) devices. The rapid growth of the complexity of modern electronic circuits has forced electronic circuit designers to rely upon computer programs to assist or automate most steps of this design process. Typical circuits today contain hundreds of thousands or millions of individual pieces or xe2x80x9ccells.xe2x80x9d Such a design is too large for a circuit designer or even an engineering team of designers to manage effectively without computer systems.
In general, the EDA system typically receives one or more high level behavioral descriptions of an IC device (e.g., in HDL languages like VHDL, Verilog, etc.) and translates this high level design language description into netlists of various levels of abstraction. At a higher level of abstraction, a generic netlist is typically produced based on technology independent primitives. The generic netlist can be translated into a lower level technology-specific netlist based on a technology-specific library that has gate-specific models for timing and power estimation, for instance. A netlist is a description of the electronic circuit which specifies what cells compose the circuit and which pins of which cells are to be connected together using wires (xe2x80x9cnetsxe2x80x9d). Importantly, the netlist does not specify where on a circuit board or silicon chip the cells are placed or where the wires run which connect them together. A netlist describes the IC design and is composed of nodes (elements) and edges, e.g., connections between nodes, and can be represented using a directed cyclic graph structure having nodes which are connected to each other with signal lines. A single node can have multiple fan-ins and multiple fan-outs. The netlist is typically stored in computer readable media within the EDA system and processed and verified using many well known techniques.
FIG. 1 illustrates a typical integrated circuit design netlist that includes a number of hierarchical organized cells including a top level block 40 having a number of lower level circuit blocks 10-30 within. Each circuit block 10-30 includes a number of cells and or other blocks.
Once the netlist is complete, the actual physical size, dimensions, geometry and placement of the cells within the blocks can be determined. Determining this geometric information is the function of an automatic placement process and an automatic routing process, both of which are parts of the xe2x80x9cphysical designxe2x80x9d process and are typically computer programs. The designer supplies the netlist into the computer implemented automatic cell placement process. The automatic placement computer program finds a location for each cell on a circuit board or silicon chip. The locations are specified, typically, in two dimensional spatial coordinates, e.g., (x, y) coordinates, on the circuit board or silicon chip. The locations are typically selected to optimize certain objectives such as wire length, wire routibility, circuit speed, circuit power consumption, and/or other criteria, and typically subject to the condition that the cells are spread evenly over the circuit board or silicon chip and that the cells do not overlap with each other. The output of the automatic cell placement process includes a data structure including the (x, y) position for each cell of the design.
Typically, placement is done in two steps including a first coarse placement process, then detailed a placement process. The coarse placement process finds approximate cell locations which optimize the desired metrics and spreads cells evenly across the silicon chip or circuit board. In the output data structure, some cells still overlap and no cells are in legal site locations, so the coarse placement needs to be legalized before the circuit can be fabricated. The detailed placement inputs the data structure output by the coarse placement and generates the detailed placement which does not have overlap and all are located on legal sites.
Next, the designer supplies the netlist and the cell location data structure, generated by the placement program, to a computer implemented automatic wire routing process. This computer program generates wire geometry within data structure. The wire geometry data structure and cell placement data structure together are used to make the final geometric database needed for fabrication of the circuit.
In executing the above physical design programs or xe2x80x9cdesign-tools,xe2x80x9d many low level commands with associated parameters, options, variables and target databases are required. In some instances, up to 1,000 of these commands may be required to merely place one block. The commands perform low level functions for the design tools, e.g., a placer, such as: 1) initializing the placer for placement; 2) performing placement on a block; 3) evaluating the result; 4) formatting the data so that it can be understood; and 5) preparing the data for the next stage in the physical design process. Therefore, while the concept of performing a placement on a block can be abstracted to a high level operation, the actual commands given to the design tool to implement that operation are quite volumous.
Furthermore, physical design tools need to be executed on each block separately and then on the whole design. Separate sets of commands are required for each block that is to be processed. During the placement, other design tools may be required to check for any design rule violations or to perform optimizations, or to add special resources such as clocks and power lines, etc. The above process is then repeated for routing. As a result, multiple sets of commands are required for each physical design process to be completed and these commands are repeated over each block. In short, the actual command set required of the designer to merely place and route the netlist 40 of FIG. 1 may require tens of thousands of low level commands which need to be input to the physical design tools in a particular order.
In an effort to address the daunting task of managing these commands, chip designers have written small xe2x80x9cexecutexe2x80x9d programs that function to access a block of the netlist and depending on which block is obtained, apply a predetermined set of commands to the block involving the physical design tools. Once a block is processed, the next one is automatically obtained. Loops can be placed in the programs for processing multiple blocks in the same way, e.g., using the same set of commands. However, the computer time required to perform a place and route on a typical design is very long. Should there be a problem with the execute program, or a problem with the placement or routing of the netlist, or a problem in one of the commands, then the entire execute program needs to be re-run from scratch once the problem is isolated and fixed. Therefore, this prior art approach is not very efficient in the face of design errors or program bugs which are always present. Furthermore, although this prior art approach helps to automate some of the designer""s job, it still requires that in the development or modification of the execute program, the designer needs to use and edit the low level, volumous detailed commands. As such, this development process can be tedious, error-prone and time consuming.
Another prior approach to solving the problem of dealing with these low level commands is utilize a program such as the UNIX Make, which is well known and commercially available. The program, Make, allows dependency graphs to be used indicating the input and the output of certain nodes, with each node representing a design tool task to be performed. In order to place and route the netlist, the graphs are analyzed to determined which nodes need which data and the appropriate node execution is then performed in the order dictated by the data dependencies. On subsequent re-runs of the netlist, if a node""s input has not changed since the last run, then the node is not executed and its output is similarly re-used. Although offering efficient executions, this prior approach requires that the entire physical design process be hand-coded in the low level commands required of the design tools. This approach does not offer any flexibility in dealing with similar blocks or in adding or deleting or modifying commands because any such activity must be performed by hand, with an editor, directly on the low level commands. For instance, to run the same design tool over various blocks requires that the same code be block copied for each block, e.g., using an editor. To change a variable or parameter within the design tools requires that the code portion relating to that design tools be identified and manually modified. Again, this approach is very tedious, error-prone and time consuming.
Accordingly, what is needed is a system and method for providing the flexibility offered by the xe2x80x9cexecute programsxe2x80x9d while still providing the execution efficiency offered by the dependency graphs described above. The present invention provides these advantages and others not specifically mentioned above but described in the sections to follow.
A method and system are described for automatically generating low level design tool commands as dependency graphs from abstracted high level physical design stages. The novel system inputs names of blocks of a hierarchical integrated circuit. Each block name has associated with it certain variables, stages and conditional statements. The stages represent a set of linked physical design processes that are to be executed on the block. Stages can be dependent on other stages and therefore are executed in-order on the block depending on how they are linked in the input set. The system automatically generates, from the input set, a dependency graph for each block. The dependency graph includes a large volume of nodes with associated parameters and options. Each node includes one or more low level program commands (xe2x80x9ctasksxe2x80x9d) for directing a number of physical design tools, e.g., programs, to perform various functions with respect to the block. Each node can receive input and generate an output. If the input to a particular node has not been altered, e.g., since the last time the graphs were executed, then that node is not executed in the current run. Dependency graphs that are not data dependent can be executed in parallel. If the input set is altered, a new set of dependency graphs can automatically be generated. By grouping the physical design operations into stages, the novel system allows the user to abstract the problem of dealing with large numbers of physical design tasks into the more manageable problem of dealing with high level xe2x80x9cstagesxe2x80x9d in the physical design process.
More specifically, an embodiment of the present invention includes a method of performing physical design operations on an integrated circuit netlist, in a computer system, said method comprising the steps of: a) accessing an input file containing identifications of a plurality of blocks of cells of the integrated circuit netlist, each block having defined therefor a respective set of linked stages representing high level physical design operations to be performed on each block; b) defining for each stage, a group of low level tasks to be performed in order to accomplish the stage, the low level tasks comprising commands, parameters and data to be supplied to physical design tools; c) automatically generating, based on the input file, a separate dependency graph for each block of the plurality of blocks by mapping the associated set of linked stages, for each block, to their corresponding low level tasks and maintaining data dependencies therein; and d) executing the dependency graphs to perform physical design operations on the integrated circuit netlist as defined by the input file, wherein only nodes of the dependency graphs having changed inputs are executed by step d).
Embodiments include the above and wherein the changed inputs of the step d) are evaluated based on the last execution of the d) for the netlist. Embodiments include the above and further comprising the steps of: e) modifying the input file wherein the set of stages is modified for at least one block of the plurality of blocks; f) performing step c) on the input file, as modified by the step e), to automatically generate modified dependency graphs; and g) performing step d) on the modified dependency graphs generated by the step f). Embodiments also include the above and wherein the high level physical design operations comprise, for each block, cell placement, cell routing, floorplanning and design rule checking.
The novel method and system described above offer several advantages over the prior art. First, by grouping the physical design tasks into high level stages, the system allows the user to abstract the problem of dealing with large numbers of physical design tasks into the more manageable problem of dealing with high level, understandable xe2x80x9cstagesxe2x80x9d in the physical design process. Second, by allowing the user to specify how to link together the stages on a per-block basis, the system allows the user to generate different dependency graphs for different blocks in the design with a minimum of effort because the stages and link information is readily understandable, at a high level, and not volumous.
Third, by including the dependencies of all blocks in one large dependency graph, the system insures that the program which executes the dependency graph has access to all information necessary to parallelize the physical design to the maximum degree thereby providing a very efficient system for executions and re-executions.
Fourth, by representing each stage with multiple nodes in a dependency graph, the system provides a number of unique and novel advantageous benefits For insance, the system achieves maximum parallel execution of tasks associated with a stage. Due to the independent nature of blocks in a hierarchical design, this means that many tasks may execute in parallel, minimizing the time to complete the entire hierarchical physical design. Also, execution time can be substantially reduced because if tasks associated with a particular node fail, the user can restart execution at that node, without the penalty of having to re-execute tasks which have previously executed successfully. Moreover, if tasks associated with a particular node fail, other tasks associated with nodes that are not dependent upon the failing node can continue execution.
Lastly, by allowing the user to readily identify the one or more target nodes in the dependency graph, the system gives the user full flexibility to execute multiple different physical design tasks in parallel.